Technical and feature overview of Azure Active Directory B2C #
A companion to About Azure Active Directory B2C, this article provides a more in-depth introduction to the service. Discussed here are the primary resources you work with in the service, its features, and how these enable you to provide a fully custom identity experience for our customers in your applications.
Azure AD B2C tenant #
In Azure Active Directory B2C (Azure AD B2C), a tenant represents our organization and is a directory of users. Each Azure AD B2C tenant is distinct and separate from other Azure AD B2C tenants. An Azure AD B2C tenant is different than an Azure Active Directory tenant, which we already have.
The primary resources you work with in an Azure AD B2C tenant are:
- Directory - The directory is where Azure AD B2C stores your users’ credentials and profile data, as well as your application registrations.
- Application registrations - You register your web, mobile, and native applications with Azure AD B2C to enable identity management. Also, any APIs you want to protect with Azure AD B2C.
- User flows and custom policies - The built-in (user flows) and fully customizable (custom policies) identity experiences for your applications.
- Use user flows for quick configuration and enablement of common identity tasks like sign up, sign in, and profile editing.
- Use custom policies to enable user experiences not only for the common identity tasks, but also for crafting support for complex identity workflows unique to your organization, customers, employees, partners, and citizens.
- Identity providers - Federation settings for:
- Social identity providers like Facebook, LinkedIn, or Twitter that you want to support in your applications.
- External identity providers that support standard identity protocols like OAuth 2.0, OpenID Connect, and more.
- Local accounts that enable users to sign up and sign in with a username (or email address or other ID) and password.
- Keys - Add and manage encryption keys for signing and validating tokens.
An Azure AD B2C tenant is the first resource you need to create to get started with Azure AD B2C. Learn how in Tutorial: Create an Azure Active Directory B2C tenant.
Accounts in Azure AD B2C #
Azure AD B2C defines several types of user accounts. Azure Active Directory, Azure Active Directory B2B, and Azure Active Directory B2C share these account types.
- Work account - Users with work accounts can manage resources in a tenant, and with an administrator role, can also manage tenants. Users with work accounts can create new consumer accounts, reset passwords, block/unblock accounts, and set permissions or assign an account to a security group.
- Guest account - External users you invite to your tenant as guests. A typical scenario for inviting a guest user to your Azure AD B2C tenant is to share administration responsibilities.
- Consumer account - Consumer accounts are the accounts created in your Azure AD B2C directory when users complete the sign-up user journey in an application you’ve registered in your tenant. This is the account type that is used for our customers.
Consumer accounts #
With a consumer account, users can sign in to the applications that you’ve secured with Azure AD B2C. Users with consumer accounts can’t, however, access Azure resources, for example the Azure portal.
A consumer account can be associated with these identity types:
- Local identity, with the username and password stored locally in the Azure AD B2C directory. We often refer to these identities as as “local accounts.”
- Social or enterprise identities, where the identity of the user is managed by a federated identity provider like Facebook, Microsoft, ADFS, or Salesforce.
A user with a consumer account can sign in with multiple identities, for example username, email, employee ID, government ID, and others. A single account can have multiple identities, both local and social.
Azure AD B2C lets us manage common attributes of consumer account profiles like display name, surname, given name, city, and others. You can also extend the Azure AD schema to store additional information about your users. For example, their country or residency, preferred language, and preferences like whether they want to subscribe to a newsletter or enable multi-factor authentication.
Learn more about the user account types in Azure AD B2C in Overview of user accounts in Azure Active Directory B2C.
External identity providers #
You can configure Azure AD B2C to allow users to sign in to your application with credentials from external social or enterprise identity providers (IdP). Azure AD B2C supports external identity providers like Facebook, Microsoft account, Google, Twitter, and any identity provider that supports OAuth 1.0, OAuth 2.0, OpenID Connect, SAML, or WS-Federation protocols.
With external identity provider federation, we can offer our consumers the ability to sign in with their existing social or enterprise accounts, without having to create a new account just for a single application.
On the sign-up or sign-in page, Azure AD B2C presents a list of external identity providers the user can choose for sign-in. Once they select one of the external identity providers, they’re taken (redirected) to the selected provider’s website to complete the sign in process. After the user successfully signs in, they’re returned back to Azure AD B2C for authentication of the account in our applications.
Identity experiences: user flows or custom policies #
The extensible policy framework of Azure AD B2C is its core strength. Policies describe our users’ identity experiences such as sign up, sign in, and profile editing.
In Azure AD B2C, there are two primary paths we can take to provide these identity experiences: user flows and custom policies.
User flows are predefined, built-in, configurable policies that we provide so we can create sign-up, sign-in, and policy editing experiences in minutes.
Custom policies enable us to create our own user journeys for complex identity experience scenarios.
Both user flows and custom policies are powered by the Identity Experience Framework, Azure AD B2C’s policy orchestration engine.
User flow #
The Azure portal includes several predefined and configurable policies called user flows.
We can configure user flow settings like these to control identity experience behaviors in our applications:
- Account types used for sign-in, such as social accounts like a Facebook, or local accounts that use an email address and password for sign-in
- Attributes to be collected from the consumer, such as first name, postal code, or country of residency
- Azure Multi-Factor Authentication (MFA)
- Customization of the user interface
- Set of claims in a token that your application receives after the user completes the user flow
- Session management
- …and more.
Most common identity scenarios for the majority of mobile, web, and single-page applications can be defined and implemented effectively with user flows. We recommend that you use the built-in user flows we have created unless you have complex user journey scenarios that require the full flexibility of custom policies.
Learn more about user flows in User flows in Azure Active Directory B2C.
Custom policy #
Custom policies unlock access to the full power of the Identity Experience Framework (IEF) orchestration engine. With custom policies, we can leverage IEF to build almost any authentication, user registration, or profile editing experience that you can imagine.
The Identity Experience Framework gives you the ability to construct user journeys with any combination of steps. For example:
- Federate with other identity providers
- First- and third-party multi-factor authentication (MFA) challenges
- Collect any user input
- Integrate with external systems using REST API communication
- Each such user journey is defined by a policy, and you can build as many or as few policies as you need to enable the best user experience for your organization.
A custom policy is defined by several XML files that refer to each other in a hierarchical chain. The XML elements define the claims schema, claims transformations, content definitions, claims providers, technical profiles, user journey orchestration steps, and other aspects of the identity experience.
The powerful flexibility of custom policies is most appropriate for when you need to build complex identity scenarios. Developers configuring custom policies must define the trusted relationships in careful detail to include metadata endpoints, exact claims exchange definitions, and configure secrets, keys, and certificates as needed by each identity provider.
Learn more about custom policies in Custom policies in Azure Active Directory B2C.
Protocols and tokens #
Azure AD B2C supports the OpenID Connect and OAuth 2.0 protocols for user journeys. In the Azure AD B2C implementation of OpenID Connect, our applications start the user journey by issuing authentication requests to Azure AD B2C.
The result of a request to Azure AD B2C is a security token, such as an ID token or access token. This security token defines the user’s identity. Tokens are received from Azure AD B2C endpoints like the /token or /authorize endpoint. With these tokens, you can access claims that can be used to validate an identity and allow access to secure resources.
For external identities, Azure AD B2C supports federation with any OAuth 1.0, OAuth 2.0, OpenID Connect, SAML, and WS-Fed identity provider.
The preceding diagram shows how Azure AD B2C can communicate using variety of protocols within the same authentication flow:
- The relying party application initiates an authorization request to Azure AD B2C using OpenID Connect.
- When a user of the application chooses to sign in using an external identity provider that uses the SAML protocol, Azure AD B2C invokes the SAML protocol to communicate with that identity provider.
- After the user completes the sign-in operation with the external identity provider, Azure AD B2C then returns the token to the relying party application using OpenID Connect.
Application integration #
When a user wants to sign in to our applications, whether it’s a web, mobile, desktop, or single-page application (SPA), the application initiates an authorization request to a user flow- or custom policy-provided endpoint. The user flow or custom policy defines and controls the user’s experience. When they complete a user flow, for example the sign-up or sign-in flow, Azure AD B2C generates a token, then redirects the user back to your application.
Multiple applications can use the same user flow or custom policy. A single application can use multiple user flows or custom policies.
For example, to sign in to an application, the application uses the sign up or sign in user flow. After the user has signed in, they may want to edit their profile, so the application initiates another authorization request, this time using the profile edit user flow.
Seamless user experiences #
In Azure AD B2C, we craft our users’ identity experiences so that the pages they’re shown blend seamlessly with the look and feel of our brand. We get nearly full control of the HTML and CSS content presented to our users when they proceed through our application’s identity journeys. With this flexibility, we can maintain brand and visual consistency between our application and Azure AD B2C.
Learn more about cistomizing the user experience.
Localization #
Language customization in Azure AD B2C allows us to accommodate different languages to suit our customer needs. Microsoft provides the translations for 36 languages, but we can also provide our own translations for any language. Even if our experience is provided for only a single language, we can customize any text on the pages.
See how localization works in Language customization in Azure Active Directory B2C.
Protect customer identities #
Azure AD B2C complies with the security, privacy, and other commitments described in the Microsoft Azure Trust Center.
Sessions are modeled as encrypted data, with the decryption key known only to the Azure AD B2C Security Token Service. A strong encryption algorithm, AES-192, is used. All communication paths are protected with TLS for confidentiality and integrity. Our Security Token Service uses an Extended Validation (EV) certificate for TLS. In general, the Security Token Service mitigates cross-site scripting (XSS) attacks by not rendering untrusted input.
Access to user data #
Azure AD B2C tenants share many characteristics with enterprise Azure Active Directory tenants used for employees and partners. Shared aspects include mechanisms for viewing administrative roles, assigning roles, and auditing activities.
You can assign roles to control who can perform certain administrative actions in Azure AD B2C, including:
- Create and manage all aspects of user flows
- Create and manage the attribute schema available to all user flows
- Configure identity providers for use in direct federation
- Create and manage trust framework policies in the Identity Experience Framework (custom policies)
- Manage secrets for federation and encryption in the Identity * Experience Framework (custom policies)
For more information about Azure AD roles, including Azure AD B2C administration role support, see Administrator role permissions in Azure Active Directory.
Multi-factor authentication (MFA) #
Azure AD B2C multi-factor authentication (MFA) helps safeguard access to data and applications while maintaining simplicity for our users. It provides additional security by requiring a second form of authentication, and delivers strong authentication by offering a range of easy-to-use authentication methods. Our users may or may not be challenged for MFA based on configuration decisions that you can make as an administrator.
See how to enable MFA in user flows in Enable multi-factor authentication in Azure Active Directory B2C.
Smart account lockout #
To prevent brute-force password guessing attempts, Azure AD B2C uses a sophisticated strategy to lock accounts based on the IP of the request, the passwords entered, and several other factors. The duration of the lockout is automatically increased based on risk and the number of attempts.
Password complexity #
During sign up or password reset, our users must supply a password that meets complexity rules. By default, Azure AD B2C enforces a strong password policy. Azure AD B2C also provides configuration options for specifying the complexity requirements of the passwords our customers use.
We can configure password complexity requirements in both user flows and custom policies.
Auditing and logs #
Azure AD B2C emits audit logs containing activity information about its resources, issued tokens, and administrator access. We use these audit logs to understand platform activity and diagnose issues. Audit log entries are available soon after the activity that generated the event occurs.
In an audit log, which is available for our Azure AD B2C tenant or for a particular user, you can find information including:
- Activities concerning the authorization of a user to access B2C resources (for example, an administrator accessing a list of B2C policies)
- Activities related to directory attributes retrieved when an administrator signs in using the Azure portal *nCreate, read, update, and delete (CRUD) operations on B2C applications
- CRUD operations on keys stored in a B2C key container
- CRUD operations on B2C resources (for example, policies and identity providers)
- Validation of user credentials and token issuance
For additional details on audit logs, see Accessing Azure AD B2C audit logs.
Usage insights #
Azure AD B2C allows us to discover when people sign up or sign in to our applications, where our users are located, and what browsers and operating systems they use. By integrating Azure Application Insights into Azure AD B2C by using custom policies, we can gain insight into how people sign up, sign in, reset their password or edit their profile. With such knowledge, we can make data-driven decisions for our upcoming development cycles.
Find out more about usage analytics in Track user behavior in Azure Active Directory B2C using Application Insights.